A blockchain is a type of computing architecture that enables a peer-to-peer distributed (shared and replicated) database or ledger, not controlled by a single organization or entity, but many different ones. Spanning across a network of independent machines, the configuration permits the nodes to reliably track and maintain the state of information in a system. In doing so, a blockchain enables the cost-efficient creation of business networks without requiring a central point of control. This configuration operates in contrast to traditional database-oriented systems, where independent parties maintain their own systems of record and reconcile updates with one another in inefficient and sometimes complex inter-organizational processes, which requires the services of an independent, trusted third-party administrator.
A blockchains use smart contracts to define the transactions conducted among various blockchain participants. Conditions for accessing and exploiting smart contracts are limited in their capacity to reduce the likelihood of unauthorized access to the blockchain assets. In some examples, the smart contracts are enacted to manage various processes for members or other authorized parties to a blockchain.
Storage ‘tiering’ helps organizations maintain a balance between performance and cost by moving data around different tiers to cope with swings in demand. Tiering ensures that data sits on the most appropriate storage configuration according to the application requirements, whether it be latency or throughput. Most research efforts have focused on traditional storage systems and tiering across different disk types. For instance, hot data residing in tier 2 (high endurance, high capacity, 10K revolution-per-minute RPM hard drives HDs) can be migrated to high performance, high cost solid state drives (SSDs) if deemed necessary. This process is called ‘up-tiering’, where a change is made from a lower class tier to a higher class tier. Similarly, cold data that is not being utilized may be migrated from a higher tier (T1) to a colder tier (T2) to make space for more up-tiering. There are many types of tiers used with different data access categories. There are usually several rules with respect to how to map data to the right tier. For example, one of the main metrics dynamic tiering systems use is referred to as input/output (IO) density, which is a function of IO/second/GB. Based on IO density, a decision may be made to up-tier or down-tier storage. Tiering can be performed for object storage, file storage, and block storage. For an object/file, access rate may be examined first, and for a block, the main parameter of interest may be IO density. An example of tier/IO density mapping for block storage may be setup as a tier to IO density correlation, for example, tier 0>=1, tier1B is 0.7-1.0, tier1B is 0.5-0.7, tier2 is 0.1-0.5, tier3 is 0.01-0.1, nearline is 0.0-0.01, inactive is 0 and unknown is null.
System administrators/automated systems will use the example metrics of a table to decide where a particular volume should be mapped. Up/down-tiering of a volume involves copying and moving a volume across tiers, these tiers could be within a data center (traditionally), across data centers (same organization/cloud), and across different organizations (e.g., a hybrid-cloud model). Tiering may be optimal for a network, but if not performed correctly (e.g., not using the right policy), there are many things that could go wrong, from a simple mistake, such as putting a volume on the wrong tier, to more serious problems where the volume is lost in-transit with no one to hold accountable. For instance, if a volume is pushed to a tier in a remote organization (e.g., third party cloud), and the volume never makes it to the remote organization, the question is then, what happened?, or who is accountable?
In a traditional tiering solution, storage is allocated and pooled into different tiers, in this example, three tiers, gold, silver, and bronze. When a file system is created/mounted, a request may be made to place the file system on a particular tier based on business needs, performance needs, etc. This process follows simple rules developed by system administrators. Similar to the block storage scenario, what tier to choose is left to the system administrator, or an automated system guided by a set of policies/rules designed by the system administrator. Automated tiering solutions rely on policies and best practices for tiering. These polices are executed by a centralized server/manager and are pre-defined, and are often pre-agreed upon, however, when other parties enter the policy circle, the question then becomes, what policy should be implemented a multi-service provider environment, different best practices may be followed, thus ending in scenarios where the end result deviates from what each party involved in the tiering transaction expected. For instance, consider a scenario where guidelines for tiering are based on best practices defined by network system architects, however, once the tiers are being used, the third parties, which may have their own policies for tiering may be in disagreement regarding the initial policies for tiering.